前言

當我開始學這些現代身份驗證架構時，才發現裡面藏著一堆看不懂的名詞:OAuth、OpenID Connect、Authorization Server、Identity Provider、Access Token、Authorization Code Flow……每一個字好像都查得到解釋，但全部放在一起，我卻完全不知道它們到底在做什麼。

所以這個系列決定先回頭把這些名詞背後最基礎的觀念搞懂，再一步步往上疊，從最基本的問題開始:

當一個系統說「這個人已經登入，而且可以存取這個 API」時，它到底做了哪些事情?

接下來的日子裡，我會一路從 Identity、Authentication、Authorization 出發，慢慢走到 OAuth 2.0、OpenID Connect、各種 Authorization Flow，最後再把這些觀念放進 Microsoft Entra External ID、AWS Cognito 等實際 Identity 平台裡。

在回答「登入到底做了哪些事」之前，得先搞懂一件更基礎的事:在系統眼中，「你」到底是什麼?這也是今天要先拆解的第一件事——身份(Identity)。搞懂 Identity 之後，再接著拆解常被搞混的四個詞:身份識別(Identification)、身份驗證(Authentication)、授權(Authorization)、存取控制(Access Control)。很多人會把它們通通簡化成「登入」，但在系統設計裡，這些詞分別對應到不同的階段與職責。

今天內容涵蓋:

1. Identity 到底是什麼
2. Identity、Identifier 與 Account 的關係
3. 身份如何被系統儲存與管理
4. 登入到底做了哪些事
5. 名詞對照表
6. 換個角度看:一次 Web API 請求裡的四個問題
7. 密碼登入的原理與風險

一、Identity 到底是什麼?

先想一個生活化的例子:一位科技業工程師，在不同情境下，其實同時擁有好幾種身份:

• 在公司，他是工程師
• 在健身房，他是會員
• 在醫院，他是病患

同一個人，但在不同情境(context)下，系統(或其他人)在乎的屬性完全不一樣:

這就是 Identity 的關鍵:同一個人不只有一種身份，而是「站在不同情境裡，被不同方式描述」。拿前面工程師的例子來說:在公司，他被描述成「工程師」;在健身房，他被描述成「會員」;在醫院，他被描述成「病患」。這三個描述，就是三個不同的 Identity。雖然都是同一個人，但每個 Identity 各自帶著一組跟該情境有關的屬性(attributes)，彼此也不會互相影響——公司不會知道他在健身房的方案到期日，健身房也不會知道他的職稱。

這個概念也不只限於人。應用程式、服務、裝置，只要是系統需要辨識並賦予權限的對象，同樣可以擁有自己的 Identity——這也是後面會提到 Service Identity、Machine Identity 的原因。

二、Identity、Identifier 與 Account 的關係

承接上面的例子，再往下拆一層，會出現另外兩個常被搞混的名詞:Identifier 與 Account。

Identifier:代表某個 Identity 的一筆資料

在特定情境下，系統需要一筆資料能唯一指向某個 Identity，這筆資料就叫做 Identifier。中文常翻成「識別碼」，它的概念其實跟 key-value 裡的 key 很接近:系統用這筆資料當查找鍵，去對應到背後那個完整的 Identity(value)。就像身分證字號、學號、訂單編號那樣，都是用來查到對應身份的一組代號。回到工程師的例子:

Identifier 有一個硬性要求:在該情境下必須是獨一無二的。如果同一筆資料同時指向兩個不同的人，它就沒辦法拿來當作辨識身份的依據——這也是為什麼員工編號、身份證字號、Email 這類資料經常被拿來當 Identifier 使用。

Account:在特定產品或服務裡執行活動的單位

Account 則是另一個層次的概念，代表在某一個特定的產品或服務裡，實際「執行活動」的單位。

多數情況下，一個 Account 會對應到一個 Identity——例如他的健身房 App 帳號，就對應到「健身房會員」這個 Identity。

一個 Account 可能跟多個 Identity 相關。比方說，用一個 App，同時支援 Google 登入 與 LINE 登入:Google 登入對應的，是你在 Google 那邊的 Identity(有自己的 Google 帳號屬性與 Identifier);LINE 登入對應的，則是你在 LINE 那邊的另一個 Identity。這兩個 Identity 本來互不相干，但只要 App 在後台把它們都連結(link)到同一個 App Account 上，你就可以不管用哪種方式登入，操作的都是同一組資料與權限。這就是多個 Identity 共用同一個 Account 的典型例子。

下面用一張圖把 Identifier、Identity、Account 三者的關係串起來:

💡三者總整理：

• Identity：像「健身房會員」，代表你在這個情境中的身分與相關資料。
• Identifier：像「會員卡號」，用來辨識你是哪一位會員。
• Account：像「健身房 App 帳號」，用來登入、預約、打卡與查課表。

三、身份如何被系統儲存與管理

Identity 通常怎麼儲存?

實務上，Identity 通常會被儲存成一筆使用者記錄，例如:

{
  "id": "usr_8f21ac"，
  "identifiers": ["gloria@example.com"， "E1023"]，
  "displayName": "Gloria Chen"，
  "department": "Finance"，
  "status": "active"，
  "createdAt": "2026-08-15T00:00:00Z"
}

誰來管理這筆記錄?

這筆記錄可能存在應用程式自己的資料庫裡，也可能交給專門的 Identity Provider(IdP)，例如 Microsoft Entra ID、AWS Cognito、Auth0 來集中管理。無論放在哪裡，它的角色都一樣:成為後續身份驗證、授權判斷時，系統查詢與比對的依據。

四、登入到底做了哪些事?

先想一個情境就好:使用者想透過某個應用程式，存取一項受保護的資源，系統這時候不能只問一句「他登入了嗎?」就決定要不要放行。

在真正把資源交出去之前，其實至少有幾個不同的問題需要先被回答:

1. 你說你是誰?
2. 你怎麼證明自己真的是這個人?
3. 這個人被允許做這件事嗎?
4. 系統最後到底要不要真的放行?

這四個問題，分別對應到身份識別(Identification)、身份驗證(Authentication)、授權(Authorization) 與 存取控制(Access Control)。

下面先用一張概念圖把它們放進同一個流程裡:

① 身份識別 Identification:你說你是誰?

流程一開始，Application 必須先知道正在操作的人是誰。因此使用者會提供一個 Identifier，例如:

gloria@example.com

這個 Email 可以告訴系統:「我是 gloria@example.com 這個帳號。」但光是講出一個帳號，還不能證明這個人真的就是 Gloria。所以 Identification 做的事情很單純:建立「你宣稱自己是誰」這件事。

② 身份驗證 Authentication:證明你真的是

接下來，系統需要驗證剛剛宣稱的身份是不是真的。這時就會用到 Credential(認證資訊)，例如密碼、OTP、安全金鑰，甚至其他驗證方式。圖中的 Application 會把 Identifier 與 Credential 交給 Authentication Service 驗證。

如果驗證成功，系統得到的結論不是:「這個人什麼都可以做。」而只是:「我現在有足夠理由相信，這個使用者確實是他所宣稱的那個身份。」 這就是 Authentication。

③ 授權 Authorization:你能不能做這件事?

知道「你是誰」之後，下一個問題才是:那你有沒有權限做現在想做的事情? 例如 Gloria 已經成功登入，但她想存取的是薪資資料，這時系統仍然需要進一步判斷:Gloria 可以讀取這份資料嗎?

Authorization Service 會根據系統的授權規則做出決策，最後得到類似:

• Allow:允許
• Deny:拒絕

所以 Authentication 成功，不代表 Authorization 一定成功。「你是誰」跟「你可以做什麼」是兩個不同問題。

④ 存取控制 Access Control:真的放行，還是真的擋下來

最後才來到真正執行的階段。

如果授權結果是 Allow，Application 就繼續存取 Resource，取得資料後回傳給使用者。

如果授權結果是 Deny，Application 就阻止這次操作，例如回傳:403 Forbidden

這就是 Access Control 最容易理解的地方:Authorization 負責做決策，Access Control 負責把這個決策真的執行出來。

五、名詞對照表

六、換個角度看:一次 Web API 請求裡的四個問題

換成一次真實的 Web API 請求，四個詞馬上會變得更具體。延續前面登入流程那張圖的例子，假設 Gloria 想登入，再存取薪資資料:

POST /login
email=gloria@example.com
password=********

這個請求其實同時做了兩件事:email 是 Identifier，宣告「我是 gloria@example.com」，這一步對應前面登入流程裡的身份識別 Identification;password 則是 Credential，用來證明這個宣稱是真的，對應流程裡的身份驗證 Authentication。Authentication Service 驗證通過後，系統才知道「這確實是 Gloria」。

驗證成功後，前端接著呼叫另一支 API:

GET /api/payroll
Authorization: Bearer xxx

這時候系統要回答的問題，已經不是「你是誰」，而是換成:

• 這個人能不能讀 payroll? → 授權 Authorization(由 Authorization Service 判斷)
• API 最後要回 200 還是 403? → 存取控制 Access Control(實際執行判斷結果)

合起來看，這一次登入加上一次 API 呼叫，完整跑過了一次跟前面登入流程一樣的四個階段:先識別、再驗證，然後授權，最後才是存取控制決定放不放行。

那麼問題來了:Bearer xxx 到底是什麼?API 為什麼光看到這串東西，就能知道這個 Request 與誰有關、又擁有哪些權限?這些問題會留到後續文章談 OAuth、OIDC、Token 時再深入探討。

七、密碼登入的原理與風險

密碼是最常見的 Credential，但它的運作方式跟很多人想的不太一樣，風險也藏在細節裡。

系統怎麼保存密碼

安全的系統不會直接保存使用者的明文密碼，而是使用專門設計的 password hashing function（如 Argon2id、bcrypt）搭配 salt，把密碼轉換成一段無法逆向還原的雜湊值後才存進資料庫。登入時，系統會用同樣的方式比對雜湊值，而不是直接比對明文。

為什麼要加 Salt

如果沒有 salt，兩個使用者用了相同密碼，雜湊結果會一模一樣，攻擊者可以靠事先算好的「雜湊對照表(rainbow table)」快速反查明文密碼。加上一段隨機的 salt 之後，即使密碼相同，每個帳號的雜湊值也會不一樣，大幅提高破解成本。

密碼登入常見的風險

• 密碼重複使用:使用者習慣在多個網站用同一組密碼，只要有一個網站外洩，其他帳號也會跟著曝險。
• 暴力破解與撞庫攻擊:攻擊者拿外洩的帳密組合，大量嘗試登入其他系統(credential stuffing)。
• 釣魚(Phishing):使用者被誘導把密碼輸入到假冒的登入頁面，再由攻擊者直接拿到明文密碼。
• 弱密碼:太短、太常見的密碼，即使有 hashing 保護，也很容易被猜到或暴力破解。

正因為單靠密碼有這些風險，實務上系統很少只靠一組密碼就把關放行，而會再搞配其他驗證方式來降低風險。

小結

前面提到，實務上系統很少只靠一組密碼就把關放行，而會再搭配其他驗證方式來降低風險。那麼問題來了，這裡說的「其他驗證方式」，具體上是什麼?而且使用者驗證成功一次之後，系統又要怎麼設計，才能在接下來每一次請求裡，都知道「這仍然是同一個已登入的使用者」?

下一篇會接著把登入安全談得更完整:什麼是 MFA(多因子驗證)、OTP 與 TOTP，又為什麼近年來 WebAuthn / Passkey 會被視為更安全也更好用的驗證方向。

參考資源

• 什麼是驗證?定義和方法 - Microsoft
• 7 Authentication Concepts Every Developer Should Know
• Password Storage Cheat Sheet - OWASP